There is no doubt that smart phones has been a necessity in modern life. Because of its handiness, more and more people prefer to put their privacy in the full-featured device: like contacts, messages, schedules, payment information, and so on. In some ways, the smart phones looks more like a housekeeper who knows everything about his master than a mobile device.
For this reason, it has been an urgent problem to protect the private information of smart phones. You need to keep the malwares away from the sensitive data, and you need to make sure that people unrelated can’t get important things about your job by your phone. Moreover, something should be invisible when your children is playing Angry Bird with your phone. Oops......maybe it is time to buy another phone.
Well, how come this happen? Different phones for different usage? Actually, what people need is multiple separated environments rather than multiple mobile phones. If we can simulate these environments in a single device, and ensure that no application in one environment can influence that in others, the problem will be solved.
Simulating multiple environment is not strange in computers. There are lots of methods, and all of them are summarized as one word: virtualization. But when it comes to mobile phones, the situation is getting troublesome. In fact, lack of resources makes some solutions sound like fantasy. Among all these solutions, container is one exception.
Container is a light-weight solution, which is supported firstly in Linux kernel. It is suitable for virtualization on mobile phones as it costs not much system resources. In traditional methods, what is virtualized is the hardware resources. But in container, it is the running environment of a process.
In Linux kernel, two features called Cgroup and Namespace are used for the container virtualization. There is an open-source project LXC (https://linuxcontainers.org), which provides series of user space tools to make the kernel features more convenient to use.
As is known to all, Android is the most popular smart phone OS, and the kernel of Android is Linux. So we choose Android and LXC to do our virtualization.
LXC can provide separated process environment. But for devices, LXC is helpless. We need to make different Android runtime to share the same physical devices. For example, the binder device, the input and display device, and so on.
Condroid(Android + Container)2.0 is a lightweight mobile virtualization solution for the relatively new Android System(Android 5.1.1).We use the same architecture to build our system on the Nexus 6. Intent to improve the performance and security of Android, the source code of Android 5.1.1 changes a lot. So we need to deal with many new problems when porting Condroid to Android 5.1.1. LXC is recompiled for the new project, some system services are modified compare to the old version.
This is a video demo of our solution.
This is the overall architecture of our solution.
In our solution, only one kernel exists in the device. The processes of android runtime is grouped and isolated by the LXC tools.
As is known to all, binder is the default IPC methods in Android, and it is implemented through a device located at /dev/binder. In our solution, we create virtual binder devices for containers to do the IPC. The virtual binder devices forward all the requests to the real destination.
There are lots of devices in android smart phones. Instead of virtualizing them one by one, we simply make the devices shared among all the containers. As the devices is abstracted to binder services, we mainly concentrate on the services in android system, like SurfaceFlinger, WindowManagerService, and so on.
Here is our display architecture, the SurfaceFlinger is shared among containers.
Here is the input part, the WindowManagerService is modified to be fit for multi containers.
This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author's copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder.